In inter-computer communication, there has been a marked increase in demands for carrying out communication of real time information for video and audio in recent years. With real time communication terminals for handling video and audio, for example, it is necessary to execute a plurality of tasks, such as tasks for receiving video and audio information from another terminal, tasks for indicating received information, and tasks for transmitting information to another terminal. Therefore, this terminal becomes a multitask system for executing a plurality of tasks requiring real time processing, and is required to ensure service quality (QoS: Quality of Service).
In this type of multitask system, as technology for ensuring service quality a task priority setting function of an OS (Operating System) is used to set the priority of tasks required to be dealt with in real time for handling video and audio high than for other tasks, and a technique for giving precedence to processing of tasks with severely delayed requests is generally used. Also, as another technique for ensuring service quality, there has been proposed a method, in a task having execution termination target time set, of, by carrying out processing in a prioritized manner such that priority is increased as this execution termination target time is approached, causing completion of task processing up to the execution termination target time (Japanese Patent Laid-open No. Sho. 62-284437).
There has also been proposed a multitask system for executing periodic tasks and executing the tasks that require delay securement from execution time, as a task management method for controlling service quality of an application program by ensuring task delay of all tasks requiring delay ensuring and controlling execution of tasks (for example, Japanese Patent laid-open No. Hei. 10-171667). There has also been proposed, in a multitask system, a multitask system for automatically correcting required processing time and permitted delay time set for each task based on actual task processing time, and executing tasks (Japanese Patent laid-open No. He. 11-259311). There is also new calculation of period used in execution of a task, required processing time and permitted delay time based on actual period and processing time of that task during operation (Japanese patent laid-open No. 2000-56989).
However, with any of these related techniques, when total required resource amount for tasks requiring execution securement exceeds resource amount capable of being provided by a system at that point in time, the system may execute tasks exceeding capacity, it is not possible to execute low priority tasks or tasks requiring new execution reservation, or it is not possible to execute all tasks, and it becomes impossible to execute within a specified deadline permitting delay.
For example, as shown in FIG. 9(a), if a resource amount R1 that a system can provide at a particular point in time is larger than total requirement resource amount of required tasks r1+r2, it is possible for the system to execute all tasks that require execution. However, from this state, in the event that additional task processing for requirement resource amount r3 is necessary, as shown in FIG. 9(b), since total requirement resource amount r1+r2+r3 is larger than resource amount R1 that can be provided, either receipt of additional tasks will be rejected or receipt of all tasks will be rejected.
Also, as shown in FIG. 10(a)-(c), taking a case of tasks A1, A2 and A3 where the period is set to S1, required processing time is set to T1, and deadline (permitted time or permitted delay time such that if processing is completed within that time quality is satisfied) is set to H1, since task A1 and task A2 can satisfy respective deadlines when they are both executed in this order (processing terminates before the deadline), they can be executed together. However, in the event that tasks A1, A2 and A3 are executed in this order, even if the deadlines for tasks A1 and A2 are satisfied, since the deadline for task A3 cannot be satisfied, it is impossible to execute task A3.
Also, when a specific application is actually in operation, for example, when adding a new task, or when correcting some tasks (tasks A1 and A2 described above), in the event that the task structure of that application is modified, if the application after that modification is actually caused to operate with that multitask system, possibility of executing each task can not be judged. Therefore, at the development stage of an application, it is necessary to repeatedly carry out installation and functional verification of prototypes many times, thus prolonging the development period, and in particular, in cases such as portable telephones having a function of downloading applications, it is very complicated in cases where both the transmit and receive sides have various hardware structures.